1. Field of the Invention
The Delta Framework Software relates generally to automated software program development and more specifically to error detection and correction during an automated software build.
2. Description of the Related Art
In a large-scale software development project, multiple developers work independently creating numerous source code components. At some point, the numerous software components must be compiled and packaged for delivery either to testers or end users. The process of compiling and packaging the numerous software components is referred to in the industry as a “software build.”
The success of the large-scale software development project depends, to a large degree, on the accuracy, reliability, and repeatability of the software build. The software build must use the correct versions of source code files, dependent library modules, and compilation and assembly tools. One way to ensure the accuracy, reliability, and repeatability of the software build is to automate the software build process. However, an automated software build requires scripts and batch files for the automation process. Moreover, the complexity of the automation code will increase as the large-scale software development project progresses. An example of a tool for an automated software build is IBM® WebSphere Studio Application Developer, when it is used in conjunction with ANT open-source tools. (See Performing Unattended Daily Builds with WebSphere Studio and ANT, parts 1-3, by Diane Bowker, David Leigh, and Mark Wainwright, Apr. 1, 2004.)
Automating a software build in a large-scale software development project also requires management of the software build because the large-scale software development project will span multiple software development disciplines and the management is often performed by using error prone and large manual processes. An example of a tool to manage large scale software development is IBM® Rational Build Forge. IBM® Rational Build Forge reduces manual activity at integration points and automatically captures relevant data for compliance, governance, and project management. Functions of IBM® Rational Build Forge include a library of best practices that are used from project to project to reduce setup time, improve scalability, and improve efficiency and quality, auto documentation of key processes to provide an audit trail of process changes for compliance management, integration with existing tools across multiple platforms, support for threading so that software builds can run concurrently in discrete processes, and pre-testing codes by running builds safely on-demand from within an Eclipse-based IDE. (See Automated Build Management for Enterprise Quality Management and Build-Driven Agility, Carey Benge, Apr. 15, 2007)
Thus, build automation, for a large-scale software development project, requires accuracy, reliability, and repeatability while spanning multiple software development disciplines. Many large-scale software development projects involve modifications to prior software deliverables requiring a code that must be written to make additions, deletions, or modifications to software previously developed. Thus, a large-scale software development project may involve a second generation build of an original software product or any number of succeeding generations of the software product. Working in large-scale development projects for revisions to prior software creates unique problems that a first time project would probably not encounter. Specifically, multiple development teams must deal with extensive modifications and complicated mixes of codes such as UML, Java, Scripts, Templates, XML, XML Transforms, and others. Thus, as multiple development teams make changes to the prior software build, the changes may cause the new software build to break.
The software build may break because breaking changes between drivers of the software build, or between drivers of the present version and the drivers of a previous generally-available version of the software build being revised, are not detected early in the software build process. For example, changes made to a software build of a new release of previously released versions of a software product can break customer's scripts, migration scenarios, scenarios where multiple versions of the product interact programmatically, scenarios where multiple versions of the product share data, established coding practices, and “stack” products that rely on certain aspects of the product being built. There are a number of existing practices to address detection of breaking changes.
One existing practice is the use of compilation and linkage checks. However, these compilation and linkage checks cannot detect code changes that affect scripts, XML templates, and other non-code artifacts during the software build. Another existing practice is to use code difference tooling. However, tools can identify dependencies that will change the build requirements of the driver, the runtime requirements of the driver or the build and runtime requirements together of the driver. However, the identification of dependencies is static and the identification of each dependency must be accomplished manually.
Another existing practice is to execute code reviews of changes between the software build and the prior released version. But to be effective in avoiding breaking changes, every change would require a code review. In addition, the code review would require the participation of subject matter experts with extensive working knowledge of the previous version contents and all possible breaking scenarios. Automated code review tools do not remedy this problem. For example, Eclipse's TPTP and XML source code analysis tools, and other automated code review tools only provide a static code analysis by comparing the code being built to a previous version of the code and identifying differences.
Finally, it is an existing practice to test the code being built for breaking scenarios. Testing the build can detect if there is a problem, but testing alone does not identify which change in the multitude of software build changes caused the problem. Therefore, additional debugging and analysis is required by either the testers or the developers, or both the testers and the developers to identify the change. Once the change is detected, additional work is necessary to implement a solution. Then, once the solution is implemented, additional testing must be conducted. Detection late in the cycle is costly. Moreover, testing for breaking scenarios is not necessarily limited to the available resources. For example, one test may detect a single breaking change, but the same type of change may not be detected in all situations, where this type of change is introduced, but not tested.
Thus, software development is often complicated by the use of different code types, extensive revisions, and multiple development teams. Detecting and tracking changes is difficult and error prone. These changes can result in incompatible or “broken” drivers or links. Present code analysis techniques are static, and are limited to detecting coding errors per se. Other code analysis techniques detect changes between code versions without identifying errors. Thus, the existing practices provide static code analysis on a single version of code, or identify the differences between two versions. However, the existing practices cannot automatically identify breaking scenarios caused by the differences and prevent the breakage. Therefore, a need exists for a way to automatically identify breaking scenarios and prevent the breakages. Moreover, a need exists for a way to detect the breaking scenarios as early as possible in the code development cycle in order to save time, money, and effort, thereby ensuring a higher quality product at a lower cost.